One manner of achieving a highly available and recoverable information technology system is employing multiple dedicated backup assets. Most if not all of the backup assets are inactive until they are activated in response to failure or disaster. Deploying such a system requires a combination of dedicated hardware, operating system (OS) software, disaster recovery (DR)/clustering middleware and application software at each recovery node for each application. For example, an application (e.g., Microsoft Exchange) would typically have a local recovery node and a global recovery node at a DR site. If a total of 3 nodes, two at the primary site and one at the DR site, are implemented, each node would be comprised of a hardware platform, an OS image, a DR/clustering middleware (e.g., Veritas), and an Exchange application. For this example, there are 2 dedicated recovery nodes that cannot be used for any other purpose. When application, OS or DR/clustering middleware patches/upgrades are released, each of the three nodes must be upgraded. If there are 5 Exchange servers in the enterprise, this translates to 15 nodes, each requiring their own dedicated server, each having a copy of the OS, application software, DR/clustering middleware and patch/upgrade management overhead.
Often, when application software and an associated OS are installed on a hardware platform, they are rigidly allocated to that platform. Typically to move this application software from one hardware platform to another, either DR/clustering middleware is used or the application software is re-provisioned at another hardware platform and application data from the original hardware platform is made available to the new platform. If this move is done across geographically dispersed locations and sub-nets, data replication and application Internet protocol (IP) change and domain name server (DNS) redirection further complicates the migration.
In many current implementations of local and global recovery, DR/clustering middleware software is used. All elements of each platform, from the input/output (I/O) cards up to the application processes, are a resource to the DR/clustering middleware software. Each platform has an agent installed through which all maintenance activities are performed. This agent has three main functional requirements: (1) it monitors all processes for the application and OS to assess its status; (2) it needs the capability to bring down the application gracefully; and (3) it needs the capability to boot up the application. To satisfy these functional requirements, there is a unique agent required for each application/OS combination. Typically, agents for popular applications/OS combinations are available by the DR/clustering middleware software provider; however, customers often have the development and maintenance responsibilities of the agents for the one off or non-popular application/OS combinations. The DR/clustering middleware software provider typically offers a development tool kit for development of the one off agents and there are consultants that can do the development for a fee. However, continuing maintenance, patch management and regression testing as OS, application or DR/clustering middleware patches and upgrades are introduced, are the responsibility of the enterprise. This translates to complexity and higher total cost of ownership (TCO).
Many technology providers offer tools and proprietary capabilities that reduce the operating and maintenance complexity of their products. However, to fully benefit from these tools and enhancements, typically a homogenous implementation of that product is required. For example, there are advantages and simplifications available if only one vendor's blade center is implemented throughout the IT system. However, if the enterprise wants to switch or mix hardware platforms, most likely the second vendor's set of tools and simplification methods are not compatible with the first vendor's.
This vendor dependency problem is more pronounced with the storage products. In general, procurement and maintenance of storage area network (SAN) products is an expensive commitment. Once a brand of SAN is implemented, there is a high cost barrier to change vendors since SAN from one vendor does not integrate/replicate with SAN from other vendors. Enterprises get locked into a vendor and have to use the same vendor's product for incremental capacity enhancements. Currently to switch SAN vendors, it has to be done in a wholesale fashion. Although new storage vendors with new simplifying innovations in scalability, performance, configuration and maintenance emerge on a regular basis, the inability to afford to phase one vendor out and another in is a large life cycle cost management concern.